home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ADA Programming Guide
/
ADA Programming Guide.iso
/
ada_lrm
/
chapb.doc
< prev
next >
Wrap
Text File
|
1996-01-30
|
11KB
|
332 lines
The following document is a draft of the corresponding chapter of the
version of the Ada Reference Manual produced in response to the Ansi
Canvass. It is given a limited circulation to Ada implementers and to
other groups contributing comments (according to the conventions defined in
RRM.comments). This draft should not be referred to in any publication.
ANSI-RM-B-v23 - Draft Chapter
B Predefined Language Pragmas
version 23
83-02-11
This revision has addressed all comments up to #5795
B. Predefined Language Pragmas
This annex defines the pragmas LIST, PAGE, and OPTIMIZE, and summarizes the
definitions given elsewhere of the remaining language-defined pragmas.
Pragma Meaning
CONTROLLED Takes the simple name of an access type as the single
argument. This pragma is only allowed immediately within
the declarative part or package specification that contains
the declaration of the access type; the declaration must
occur before the pragma. This pragma is not allowed for a
derived type. This pragma specifies that automatic storage
reclamation must not be performed for objects designated by
values of the access type, except upon leaving the innermost
block statement, subprogram body, or task body that encloses
the access type declaration, or after leaving the main
program (see 4.8).
ELABORATE Takes one or more simple names denoting library units as
arguments. This pragma is only allowed immediately after
the context clause of a compilation unit (before the
subsequent library unit or secondary unit). Each argument
must be the simple name of a library unit mentioned by the
context clause. This pragma specifies that the
corresponding library unit body must be elaborated before
the given compilation unit. If the given compilation unit
is a subunit, the library unit body must be elaborated
before the body of the ancestor library unit of the subunit
(see 10.5).
INLINE Takes one or more names as arguments; each name is either
the name of a subprogram or the name of a generic
subprogram. This pragma is only allowed at the place of a
declarative item in a declarative part or package
specification, or after a library unit in a compilation, but
before any subsequent compilation unit. This pragma
specifies that the subprogram bodies should be expanded
inline at each call whenever possible; in the case of a
generic subprogram, the pragma applies to calls of its
instantiations (see 6.3.2).
INTERFACE Takes a language name and a subprogram name as arguments.
This pragma is allowed at the place of a declarative item,
and must apply in this case to a subprogram declared by an
earlier declarative item of the same declarative part or
package specification. This pragma is also allowed for a
library unit; in this case the pragma must appear after the
B - 1
subprogram declaration, and before any subsequent
compilation unit. This pragma specifies the other language
(and thereby the calling conventions) and informs the
compiler that an object module will be supplied for the
corresponding subprogram (see 13.9).
LIST Takes one of the identifiers ON or OFF as the single
argument. This pragma is allowed anywhere a pragma is
allowed. It specifies that listing of the compilation is to
be continued or suspended until a LIST pragma with the
opposite argument is given within the same compilation. The
pragma itself is always listed if the compiler is producing
a listing.
MEMORY_SIZE Takes a numeric literal as the single argument. This pragma
is only allowed at the start of a compilation, before the
first compilation unit (if any) of the compilation. The
effect of this pragma is to use the value of the specified
numeric literal for the definition of the named number
MEMORY_SIZE (see 13.7).
B - 2
OPTIMIZE Takes one of the identifiers TIME or SPACE as the single
argument. This pragma is only allowed within a declarative
part and it applies to the block or body enclosing the
declarative part. It specifies whether time or space is the
primary optimization criterion.
PACK Takes the simple name of a record or array type as the
single argument. The allowed positions for this pragma, and
the restrictions on the named type, are governed by the same
rules as for a representation clause. The pragma specifies
that storage minimization should be the main criterion when
selecting the representation of the given type (see 13.1).
PAGE This pragma has no argument, and is allowed anywhere a
pragma is allowed. It specifies that the program text which
follows the pragma should start on a new page (if the
compiler is currently producing a listing).
PRIORITY Takes a static expression of the predefined integer subtype
PRIORITY as the single argument. This pragma is only
allowed within the specification of a task unit or
immediately within the outermost declarative part of a main
program. It specifies the priority of the task (or tasks of
the task type) or the priority of the main program (see
9.8).
SHARED Takes the simple name of a variable as the single argument.
This pragma is allowed only for a variable declared by an
object declaration and whose type is a scalar or access
type; the variable declaration and the pragma must both
occur (in this order) immediately within the same
declarative part or package specification. This pragma
specifies that every read or update of the variable is a
synchronization point for that variable. An implementation
must restrict the objects for which this pragma is allowed
to objects for which each of direct reading and direct
updating is implemented as an indivisible operation (see
9.11).
STORAGE_UNIT Takes a numeric literal as the single argument. This pragma
is only allowed at the start of a compilation, before the
first compilation unit (if any) of the compilation. The
effect of this pragma is to use the value of the specified
numeric literal for the definition of the named number
STORAGE_UNIT (see 13.7).
SUPPRESS Takes as arguments the identifier of a check and optionally
also the name of either an object, a type or subtype, a
subprogram, a task unit, or a generic unit. This pragma is
only allowed either immediately within a declarative part or
immediately within a package specification. In the latter
case, the only allowed form is with a name that denotes an
entity (or several overloaded subprograms) declared
immediately within the package specification. The
permission to omit the given check extends from the place of
B - 3
the pragma to the end of the declarative region associated
with the innermost enclosing block statement or program
unit. For a pragma given in a package specification, the
permission extends to the end of the scope of the named
entity.
If the pragma includes a name, the permission to omit the
given check is further restricted: it is given only for
operations on the named object or on all objects of the base
type of a named type or subtype; for calls of a named
subprogram; for activations of tasks of the named task
type; or for instantiations of the given generic unit (see
11.7).
SYSTEM_NAME Takes an enumeration literal as the single argument. This
pragma is only allowed at the start of a compilation, before
the first compilation unit (if any) of the compilation. The
effect of this pragma is to use the enumeration literal with
the specified identifier for the definition of the constant
SYSTEM_NAME. This pragma is only allowed if the specified
identifier corresponds to one of the literals of the type
NAME declared in the package SYSTEM (see 13.7).
B - 4